コードの良し悪しを判定するのに使える考え方
いろいろな原則があるが、重複する概念も多い
同じことを違う言葉で表現していたり
同じ概念だけどフォーカスする例が違ったりする
抽象度が高いものも低いものまとめてこう呼ばれている
コードの良し悪しを判定するのに使える考え方
いろいろな原則があるが、重複する概念も多い
同じことを違う言葉で表現していたり
同じ概念だけどフォーカスする例が違ったりする
抽象度が高いものも低いものまとめてこう呼ばれている
Unity開発で使える設計の話+Zenjectの紹介
Unityにかかわらずモデリングやクラス設計の考え方が書いてある
クラス図の読み方
SOLID原則 #ソフトウェア設計原則
https://www.slideshare.net/torisoup/unityzenject/39
コードを追加/修正するときに他のモジュールに影響させない
a.k.a. OCP Open–closed principle
拡張に対して開いていて
修正に対して閉じている
?🤔?
a.k.a. Single responsibility principle
2つ以上の変更から影響を受けるクラスは、単一責任原則をみたさない
UNIX哲学にも同じようなことが書いてある
役割駆動設計で巨大クラスを爆殺する - Qiita
#ソフトウェア設計原則
元のエッセイ:The Rise of "Worse is Better"
「悪い方が良い」原則と僕の体験談|Rui Ueyama|note
Worse Is Better に関する自分の解釈は「設計の正しさ/美しさと実装の単純さが対立する(両立できない)ときは、実装の単純さを選択した方が、たとえそれが漏れのある抽象になったとしても現実の問題を解決し、実装の単純さによって開発参加のハードルが下がり、進化的な強さを獲得できる」というもの
同じでないものを共通化しようとしないこと
https://twitter.com/MinoDriven/status/1127539251761909760
#ソフトウェア設計原則
Don't repeat yourself
The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". The principle has been formulated by Andy Hunt and [Dave
Write everything twice.
#ソフトウェア設計原則
「メモリを途中で解放してもたかが知れてるから最後まで解放しないほうが単純」とか「抽象化せず多少重複したコードを書くほうが簡単」とか主張するのは勇気がいります。XX原則に従ってないとか必ず言われるからね。でも多分そんなに難しく考える必要ないと思う。簡単に書くのが一番重要。
https://twitter.com/rui314/status/1036607815077359616?s=21 by ruiさん